Executed Workload

ABSTRACT

Methods and apparatuses enable generation of an executed workload electronic record. The executed workload record indicates data related to one or more performance metrics by which performance of a work task is evaluated. One such performance metric is an expected time for completion of the task. Performance of the task can be monitored to determine an actual completion time for the task to compare against an expected completion time. The executed workload record can be used for evaluation of workers. Executed workload records provide centralized, aggregatable information for evaluation purposes.

FIELD

Embodiments of the invention relate to electronic records, and moreparticularly to performance records having evaluation metrics toindicate work performance.

BACKGROUND

Companies hire employees to perform the work of the company. The companyhas an interest in verifying that the employees are performing theirwork as expected. The company and the employees have an interest inevaluating the employees to properly compensate them for the workperformed (e.g., giving bonuses to productive employees), or todetermine areas where an employee might be more productive (e.g.,perhaps the employee is in need of training).

Current work management systems are inadequate at providing theinformation a manager wants to be able to fairly evaluate and compensatean employee. With traditional management systems, information, ifavailable at all, is frequently spread across different systems and/ordifferent company records. Attempting to synthesize the information maybe difficult, and there may be information that is unavailable forconsideration.

One example situation of the above occurs in warehouse management.Warehouse management systems exist, but suffer the problems discussedabove. Thus, for a warehouse manager to track and monitor what warehouseworkers were doing during certain periods of time, the manager typicallyhas to access many different types of documents or electronic records,which may include warehouse orders, warehouse tasks, value added serviceorders, quality inspection documents, inventory documents, etc.Traditionally, such documents or records are not all compatible; yet,only compatible records can traditionally be merged. The warehousemanager may not be able, due to time constraints and/or inability toaccess information, to fairly compare planned work to actual performanceof tasks.

Another problem with traditional systems is that companies generallyhave what could be considered tasks related to the core business of thecompany, and tasks not related to the core business. Prior systems makeno distinction in types of work tasks in such a manner. Traditionalwarehouse management systems do not even have a provision for trackingnon-core tasks. Thus, traditional systems lack the ability to providethe information a manager needs to provide a fair evaluation of workperformed in the company. What information might be available isdistributed and not easily accessible, resulting in ineffectivemanagement, and inefficient use of time.

SUMMARY

Methods and apparatuses provide for an executed workload that indicatesone or more performance metrics related to the performance of a worktask. An example of a performance metric is a time for completion of thetask. In one embodiment, a planning document is received that indicatesthe task and one or more performance metrics. Based on a time ofcompletion of the task, an actual time for completion of the task can bedetermined. An executed workload is generated that identifies the taskand the performer and indicates a value for at least one taskperformance metric. The executed workload is stored to create a recordof the task performance.

The task to be completed can be a task related to a core business, or anindirect labor task (e.g., housekeeping details). Thus, work records canbe created for both core business labor as well as non-core businesslabor. In one embodiment, the executed workload links to a source orderor document that initiates the task. Such a source could include furtherdetails regarding resources to use for the task, or other circumstantialdetails. The circumstance data can be applicable to make sure evaluationof services is made in a consistent and fair manner.

In one embodiment, a time of completion is generated in reference to anexpected time for completion that is a base time adjusted for specificdetails of the performance (conditions, resources to be used, etc.). Inone embodiment, performance data is aggregated. Because the executedworkload provides performance data, the data for multiple performersacross multiple different types of tasks can be obtained from aconsistent form. The data allows for the fair assessment of workperformed, accounting for specific details of the conditions associatedwith performance, which are stored or referenced in the executedworkload.

BRIEF DESCRIPTION OF THE DRAWINGS

The following description includes discussion of figures havingillustrations given by way of example of implementations of embodimentsof the invention. The drawings should be understood by way of example,and not by way of limitation. As used herein, references to one or more“embodiments” are to be understood as describing a particular feature,structure, or characteristic included in at least one implementation ofthe invention. Thus, phrases such as “in one embodiment” or “in analternate embodiment” appearing herein describe various embodiments andimplementations of the invention, and do not necessarily all refer tothe same embodiment. However, they are also not necessarily mutuallyexclusive.

FIG. 1 is a block diagram of an embodiment of a planned workloadgenerated from a warehouse order and an executed workload generated fromthe planned workload.

FIG. 2 is a block diagram of an embodiment of a system that generates aplanned workload and an executed workload.

FIG. 3 is a block diagram of an embodiment of an executed workloadgenerated from a planned workload.

FIGS. 4A-4F are block diagrams of an embodiment of an exampleapplication of an executed workload.

FIG. 5 is a flow diagram of an embodiment of a process for generating anexecuted workload.

Descriptions of certain details and implementations follow, including adescription of the figures, which may depict some or all of theembodiments described below, as well as discussing other potentialembodiments or implementations of the inventive concepts presentedherein. An overview of embodiments of the invention is provided below,followed by a more detailed description with reference to the drawings.

DETAILED DESCRIPTION

As described herein, an executed workload includes information relatedto the performance of one or more tasks. The executed workload may bereferred to as an executed workload document or an electronic record. Asused herein, a “document” may refer to traditional concepts of adocument, which generally is understood to have information in a file,or something that can be viewed on a screen in a “layout” form, and canbe printed onto a sheet of paper. However, a document can also refermore generally to information having a format, and sharing somerelationship. Thus, information in a traditional “paper” style documentis part of the same layout. Information could also be related as beingof the same type, related to the same task, etc. A document as describedherein may include one or more data objects that are part of thedocument. The executed workload may be referred to as an executedworkload electronic record. An electronic record may refer to a singleset of data (e.g., multiple fields), or multiple sets of data having acommon layout (e.g., a table). Thus, a record can refer to a singleinstance of data for a single task, or multiple instances of datarelated to multiple tasks. Note that similar to a document, anelectronic record as described herein may also include one or moreobjects. A planned workload can also be a document or a record asdescribed above, but containing performance expectations rather thanactual performance data.

With the executed workload, all information about a work task may beavailable from a single source, such as when, what, where, how long, howmuch work was planned, when the work started, when it ended, and whoexecuted the task. Such aggregated information provides a manager theability to access and process the data in an efficient manner. All datanecessary for evaluation of performance can be provided in the singleexecuted workload record. With the data in a single accessible location,and in a consistent formatting, a manager could more easily provide thedata to, for example, a connected HR (human resources) system todetermine a bonus for a worker, or a group. Standard warehousemanagement systems do not offer a central document that holds allinformation necessary for evaluation of performance, and information formaking evaluations fair (normalizing the data for the conditions of theperformance). For monitoring and analysis purposes in typical managementsystems, only documents of the same kind can easily be compared. Havinga single format for the data allows comparison and merger.

With the executed workload, the comparison of planned and actual timedurations for different workers, or different groups can be includedwithin a single data source (the executed workload) to allow fairconclusions about individual or group performance. In one embodiment, awarehouse manager gathers information at regular intervals to understandthe duration, weight, and volume of product in reference to a warehousenumber, area, and month in which a warehouse has produced workload.

In one embodiment, indirect labor is also monitored. Traditional plannedworkload indicates a task and provides expectations for performance ofthe task (e.g., how much time it will take to perform). Traditionalplanned workloads are limited to direct-labor tasks or core businesstasks, or tasks that directly contribute to producing and/or shipping aproduct (e.g., manufacturing, testing/inspection, moving product withina warehouse, value added services, inventory count, etc.). As usedherein, indirect labor tasks or non-core business tasks can refer toanything that is not a direct-labor task. Examples may include smallmaintenance or housekeeping tasks, accounting for unforeseen downtime(e.g., power outage, system failure, etc., which may unexpectedlyprevent work from being done), etc. In one embodiment, the systemgenerates an executed workload for every indirect labor task. Theaddition of the executed workload for indirect labor provides a morecomplete picture of what a warehouse worker does during a certain periodof time, and provides the information in a location where otherperformance information is gathered and analyzed.

With the executed workload, it is possible for a manager to makedecisions based on monitoring only one type of record, the executedworkload. Apart from the tasks related to the core business of thewarehouse, such as those provided in warehouse orders or warehousetasks, realistic performance expectations can be considered based on theindirect labor required of workers. In one embodiment, the system allowsa manager to create a single performance document for a selected periodof time (a time which can be designated by the manager, or can be chosenfrom among pre-defined options such as month, week, or quarter). Theperformance document includes planned and actual time compared withattendance, for example, as obtained from the executed workload. Theplanned and actual times are obtained from the executed workload, andattendance for the evaluation period can be obtained, for example, froma time management system. Following a configurable release strategy ofthe performance document, the system can enable the document to betransferred to HR to be included in the payroll run. The executedworkload can provide a framework for information that ensures thatperformance data is the same regardless of the task or the performer.Thus, similar information can be maintained for each task, which allowsdifferent tasks and performers to be evaluated on the same performancemetrics or performance criteria.

In one embodiment, the executed workload includes information related toengineered labor standards (ELS). Engineered labor standards provideproductivity goals for workers and performance measurement standards formanagement. In one embodiment, performance metrics can be understood asELS metrics, which would be structured within a company and sharedbetween management and work force. Whether as ELS or some otherperformance metric, the executed workload can provide uniform standardsto rate and/or evaluate performance.

In one embodiment, the executed workload is created at the completion ofa task. That is, the completion of a task can act as a trigger to causethe system to generate the executed workload. Data that is generatedrelative to performance of the task may be stored in memory until theexecuted workload is generated. In one embodiment, data generatedrelative to performance of the task is stored as planned workload (e.g.,as data in the document) until the executed workload is generated. Theexecuted workload can be generated either when the entire task isconfirmed or when parts of the task are confirmed. Alternatively, theexecuted workload could be generated when the task is assigned, and theinformation populated either as work is performed, or populated uponcompletion of the task.

In one embodiment, the executed workload is editable. That is, after theexecuted workload is generated by the system, a manager or othersupervisory entity could manually edit the information in the executedworkload to adjust for some condition or error in recording theinformation. Also, an executed workload could be manually edited, forexample, to account for system downtime or some other unexpectedoccurrence.

Note that the discussion above, as well as the discussion below withreference to the figures makes reference to work in a warehouse. It willbe understood that such references are merely exemplary, and theexecuted workload concepts discussed herein could be applied to avariety of work scenarios or companies.

FIG. 1 is a block diagram of an embodiment of a planned workloadgenerated from a warehouse order and an executed workload generated fromthe planned workload. Work package 110 represents any type of work orderthat triggers the performance of one or more tasks. Work package 110 maybe applied in a warehouse, for example, to the movement of a pallet ofgoods, the unloading of a shipping container or truck, the packaging andshipping of a product, etc. An example of work package 110 is awarehouse order.

The work requested by work package 110 is represented by work assignment160, which may include direct labor 162 and/or indirect labor 164.Direct labor 162, as discussed above, refers to work related to the corebusiness of a company. Indirect labor 164 refers to any other work thatcannot be accounted for as direct labor 162. Work assignment 160 has anassociated identifier 114, by which the system can reference the work.In one embodiment, work package 110 includes a description of one ormore resources 116, which define what resources are to be used toperform work assignment 140. Resource 116 may be any type of equipmentsuch as tools, forklifts, testing stations, etc., as well as areas inwhich to perform the work or paths to use to move goods. The system candetermine prior to making the assignment what resources to use. Theresources used may have an effect on what performance would be expected(e.g., use of a slower forklift may increase expected performance time),as discussed more below.

Based on work package 110, the system plans how the work will beassigned and where the work will be performed. The system generatesplanned workload 120 from the work plans. Although the amount ofinformation and the information fields may differ on eachimplementation, planned workload 120 is illustrated with representativedetails. A different planned workload can be generated based ondifferent work to perform, different companies, different systems, etc.

Planned workload 120 is illustrated with work unit identifier (ID) 122A,which identifies the unit of work that is to be performed. Theidentifier can be unique to enable the system to reference the specificactivity. Activity type 124 indicates the work type, such as picking,packing, loading, etc. Activity area 126 designates an area of awarehouse or work place where the activity identified by work unit ID122 is to be performed (e.g., testing station 5). Reference document(doc) 128 provides a reference to work package 110 or a documentassociated with work package 110, such as a warehouse order. Plannedduration 129 indicates how long the task is expected to take. Plannedduration 129 can be based on ELS standards. In one embodiment, plannedduration 129 is an adjusted planned duration, which adjusts a standardexpected duration to account for specifics related to a task. That is,assume that a task nominally takes 30 minutes to complete, but isexpected to take 35 minutes because of the particular forklift(resource) selected, a particular station location or travel pathselected, or a particular disability of the assigned worker. Thus, faircomparison may be to the adjusted value rather than a nominal value.

The timing of the generation of executed workload 130 can be differentfor different implementations. In one embodiment, executed workload 130could be generated when a work assignment is generated to a specificperson. Alternatively, as illustrated, executed workload 130 could begenerated when the work assignment is completed. Such a time may beindicated by a worker inputting a key combination on a computer system,pressing a button on a machine (e.g., a wireless scanner), or finishes abatch of work (e.g., the system knows that a certain number of productunits have been sent to the worker and also received from the worker).

Executed workload 130 may be considered to be generated from plannedworkload 120, and include data of planned workload 120. Including dataof planned workload 120 refers to including at least one data elementindicated in planned workload 120. The data element may be read fromplanned workload 120, or read or received from the system. In oneembodiment, executed workload 130 includes all data indicated in plannedworkload 120. Thus, executed workload 130 may include one or more ofwork unit ID 122B, activity type 124, activity area 126, referencedocument 128, and/or planned duration 129. Work unit ID 122B may bedifferent for executed workload 130 than work unit ID 122A of plannedworkload 120. For example, work unit ID 122B may be a technical key thatis unrelated to work unit ID 122A. Note that reference document 128 maybe implemented as a link in executed workload 130 to not simplyreference work package 110, but provide an access mechanism to it (e.g.,clicking on a display of reference document 128 in executed workload 130may open work package 1 10). In one embodiment, the link for workpackage 110 is reference document 128 together with reference type 152,which identifies a type of the reference document, and organizationalunit 154, which identifies a physical or organizational unit (e.g., asupply chain unit).

Executed workload 130 indicates performer 132, which is the worker thatperforms the task. The worker may be identified by name, employeenumber, user ID, or via some other mechanism. The discussion of plannedduration 129 above made reference to an adjusted or revised version ofthe planned duration. Such a concept is illustrated explicitly inexecuted workload 130 with revised P-duration (planned duration) 134.Executed workload 130 may include the original (nominal) work timeestimate, as well as revised planned duration 134 to indicate moreinformation to a manager or other data consumer. Executed workload 130includes actual time 136, which indicates the actual time of performancefor the task associated with executed workload 130 (as indicated by workunit ID 122). The actual time may be an amount of time and/or may bevalues indicating a start and stop time of the task, from which theduration may be derived.

Executed workload 130 can also include other details related to the workperformed, such as weight 138, distance 140, volume 142, and capacity144. Weight 138 and volume 142 refer to potentially measurablecharacteristics of an item that is the subject of a work task (e.g., aweight or volume of a pallet or container. Distance 140 refers to acharacteristic of how the work will be performed (e.g., how far thegoods must be moved). Capacity 144 refers to a dimensionless number thata customer may use to indicate the resource consumption for theexecution of the different tasks. In a warehouse context, the bins mayhave a capacity, and the products themselves may have a certain capacityfor a given quantity and unit of measure. Moving a product from one binto another would alter the capacity usage of the bins accordingly. Itwill be understood that such data items are merely examples, and othertypes of characteristics referring to a measurable characteristics ofthe work item, or a characteristic of how work is to be performed, or acharacteristic of a performer could be used as alternatives or inaddition to what is illustrated.

In one embodiment, planned workload 120 is deleted from the system whenthe work is performed or in response to receiving an indication of theperformance of the work, and all performance data, planned and actual,is available through executed workload 130.

FIG. 2 is a block diagram of an embodiment of a system that generates aplanned workload and an executed workload. System 200 provides anexample of a system in which an executed workload may be generated.Warehouse management (mgt) 210 represents hardware and softwarecomponents that provide a management system. For example, warehousemanagement 210 could be a server having management system software thatmonitors and manages work within a warehouse. Warehouse management 210is illustrated with various functional blocks, which representcapabilities of warehouse management 210. The capabilities enablewarehouse management 210 to operate, and may be provided via hardware orsoftware modules or a combination.

Warehouse order (WH/O) generator 212 enables warehouse management 210 tocreate warehouse orders. In one embodiment, a warehouse order is createdon the same system that generates planned and executed workloads.Alternatively, warehouse orders may be received at warehouse management210, in response to which planned and executed workloads will becreated. The warehouse order indicates a task to perform, and includesdetails about the task, including details about the work itself or howit is to be performed. Whether generated or received, warehouse ordersmay be stored in storage system 236.

Warehouse (WH) task generator 214 enables warehouse management 210 togenerate warehouse tasks (WTs) for work such as moving goods into, outof, or within a warehouse (they may also be referred to as transferorders). A warehouse order may include multiple WTs (e.g., a separate WTmay be generated for different handling units (HUs) of the same overalltask). A warehouse task may be indicated within one or both of theplanned or executed workloads to associate the work with specific taskidentifiers. In one embodiment, the individual WTs are referenced onlyin the planned workload, while the executed workload contains onlyreference to a warehouse order rather than to the WTs. Thus, the plannedworkload may be finer-grained than the executed workload. The quantitiesof all the WTs assigned to the warehouse order may be included in theexecuted workload.

Work type determiner 216 enables warehouse management 210 identifyand/or designate a type of work for a particular task. Work may bedirect labor or indirect labor, as discussed previously. In oneembodiment, a work assignment can include work of both types, which maybe designated in a work assignment record for purposes of management andmonitoring.

Resource determiner 218 enables warehouse management 210 to identifyresources associated with performance of a task. The resources can bespecified in detail to indicate what tools, vehicles, locations, etc.,are to be used in the performance of a task. Such planning can “checkout” certain resources for certain times to assist in scheduling. Also,such planning can indicate whether a task may be completed, or whether anecessary resource is not yet available to begin the task. Details ofhow a particular resource might affect performance can also be indicatedto be factored into evaluation of performance.

Assignment generator 220 enables warehouse management 210 to generatework assignments and records related to planning and performance of theassignment. Thus, in one embodiment, assignment generator 220 mayinclude planned workload (WL) generator 222 and executed workloadgenerator 224. The details of the planned and executed workloads arediscussed throughout, and will not be further detailed here. Plannedworkload generator 222 generates planned workload 226, which is sent toexecution station 240 from where the work will be performed.

Execution station 240 represents hardware and software with which aworker may interact with the system, for example, to receive assignmentsand input data. Execution station 240 may be fixed, such as aworkstation or computer terminal, or alternatively may be mobile, suchas a handheld computing device, a multi-function scanner/input device,etc. Execution station 240 may include several modules, such as plannedworkload receiver 242, completion indicator 244, and data transmitter246. Planned workload receiver 242 enables execution station 240 toreceive work assignments. Execution station 240 may receive the plannedworkload itself, or an identifier that can be referenced. Completionindicator 244 enables a worker to indicate completion of a work taskfrom execution station 240. Data transmitter 246 may be, for example, awired or wireless link to warehouse management 210 that enablesexecution station 240 to pass performance data to warehouse management210. The data may be raw data associated with a planned workloadidentifier, or the data could be loaded into fields of a form or aworkload document. It is also possible to develop a system that enablesexecution station 240 to generate an executed workload and pass therecord to warehouse management 210.

Thus, execution station 240 generates execution or performance data 228and sends it to warehouse management 210. In one embodiment, executedworkload generator 224 creates the executed workload from the receivedexecution data 228.

System 200 may also include memory 202, which may be volatile memorysuch as some form of random access memory (RAM), or a flash memory.Memory 202 enables system data to be stored and used. For example,execution data 228 could be generated over the course of execution ofthe work task, and stored item by item as the data is created. Such datacan be stored in memory for use in creating the executed workload.Memory 202 may be accessible to both execution station 240 and warehousemanagement 210. Memory 202 may represent separate memory devices, suchas an implementation where execution station 240 includes a memorydevice that stores execution data, which is then sent to warehousemanagement 210 and stored in a memory device.

Whether created by execution station 240 or warehouse management 210, anexecuted workload is created that includes details of performance of thework task, as well as expectations of the performance. The executedworkload is stored in storage system 236. In one embodiment, executedworkload is stored in one or more backend systems, represented bybackend 234. Note that backend 234 may represent the backend systemitself that is hosted on the same server as the warehouse managementsystem, or may represent the interfaces with which warehouse management210 communicates with such a backend system. In one embodiment, detailsof the planned workload are obtained from backend 234. For example,resource determiner 218 may obtain resource detail information from oneor more backend systems.

In one embodiment, warehouse management 210 includes executionaggregator 232, which warehouse management 210 to aggregate data frommultiple executed workloads. The executed workloads from which data isaggregated may be stored in storage system 236, and/or in one or morebackend systems 234. Note that the ability to aggregate performance datais possible because the data is stored with common formatting or commonlayout, in the same type of documents (an executed workload). Such anability contrasts with prior known management systems where data isdistributed in incompatible forms. Execution aggregator 232 enables amanager to generate performance reports or evaluation data from theexecuted workloads that are stored. The executed workload can have atime stamp, or have an identifier that indicates when the executedworkload was created or when the work indicated by the executed workloadwas performed. Evaluation reports can specify an evaluation period,which is a period of time (e.g., a week, a month, a quarter, between 10Jul. 2007 to 24 Jul. 2007, etc.). Executed workloads corresponding tothe evaluation period can be selectively aggregated. Selectiveaggregation may involve selecting all executed workloads for aparticular performer, for a particular department, for a particulargroup (multiple performers), etc. Performance data can also beaggregated based on work type (e.g., all work tasks for all performersover the evaluation period, all indirect labor tasks over the evaluationperiod, etc.). Thus, a management system with warehouse management 210as described herein provides more complete evaluation and comparisondata, which is easier to access, and more readily available than what isprovided in traditional systems.

Various components referred to herein as modules, clients, engines, oragents described herein may be a means for performing the functionsdescribed. Each component described herein includes software orhardware, or a combination of these. The components can be implementedas software modules, hardware modules, special-purpose hardware (e.g.,application specific hardware, application specific integrated circuits(ASICs), digital signal processors (DSPs), etc.), embedded controllers,hardwired circuitry, etc. Software content (e.g., data, instructions,configuration) may be provided via an article of manufacture including amachine readable medium, which provides content that representsinstructions that can be executed. The content may result in a machineperforming various functions/operations described herein. A machinereadable medium includes any mechanism that provides (i.e., storesand/or transmits) information in a form accessible by a machine (e.g.,computing device, electronic system, etc.), such asrecordable/non-recordable media (e.g., read only memory (ROM), randomaccess memory (RAM), magnetic disk storage media, optical storage media,flash memory devices, etc.). The content may be directly executable(“object” or “executable” form), source code, or difference code(“delta” or “patch” code). A machine readable medium may also include astorage or database from which content can be downloaded. A machinereadable medium may also include a device or product having contentstored thereon at a time of sale or delivery. Thus, delivering a devicewith stored content, or offering content for download over acommunication medium may be understood as providing an article ofmanufacture with such content described herein.

FIG. 3 is a block diagram of an embodiment of an executed workloadgenerated from a planned workload. Planned workload 302 is an example ofa planned workload as described herein. Planned workload 302 illustratestypes of data that may be included within a planned workload. Inessence, a planned workload may include information indicating what 310work is to be done, and where 320 it is to be performed. Details ofplanned workload 302 can include a list of task IDs, and work areas.Planned workload 302 may also include the planned work type 330 (forexample, what process to perform), and source 340 of the work (e.g., anidentification of the warehouse order (WH/O) that generated the work).Planned workload 302 also includes one or more performance metrics, suchas planned time 350, which indicates a time estimate for each task.

Executed workload 304 is an example of an executed workload as describedherein. As illustrated, executed workload 304 includes the data ofplanned workload 302, and thus includes what 310, where 320, work type330, source 340, and planned time 350. Not every implementation of anexecuted workload will include all data of the planned workload. Inaddition to data of planned workload 302, executed workload 304 includesexecution details, such as who 370 performed the work (e.g., asidentified by an employee ID), and execution time 380 that indicates atotal time of the work (alternatively, start and stop times could berecorded in executed workload 304). The performance data is recorded inexecuted workload for later access and comparison.

FIGS. 4A-4F are block diagrams of an embodiment of an exampleapplication of an executed workload. The planned workload and executedworkload records as illustrated correspond to different phases of workwithin a warehouse. The various records have information relating one toanother and/or to source documents that triggered the work for which theworkload is indicative. Specifically, an outbound warehouse process isillustrated in the separate figures. Each phase will be described inturn.

FIG. 4A illustrates planned workload 410, which indicates the plannedworkload for three separate warehouse tasks (WT), 12345, 12346, and12347 related to a warehouse order, WH/O 1001. Picking for the three WTsis identified by ID 4710, for Picking process of area PI01 (e.g., aPicking station). The planned duration (PDURA) is 30 minutes to pull theproduct for the three WTs. Each WT includes a Packing, Staging, andLoading aspect. The Packing (at station PA01), Staging (at stationST01), and Loading (at station LO01) stages are identified by identifier4711 for WT 12345, with estimated times of 20 minutes, 10 minutes, and10 minutes, respectively. The Packing (at station PA01), Staging (atstation ST01), and Loading (at station LO01) stages are identified byidentifier 4712 for WT 12346, with estimated times of 30 minutes, 10minutes, and 10 minutes, respectively. Note that the same stations areintended to be used, which is reflective of the fact that the sameperformer will likely perform all the listed tasks, and will handle theWTs consecutively. The Packing (at station PA01), Staging (at stationST01), and Loading (at station LO01) stages are identified by identifier4713 for WT 12347, with estimated times of 10 minutes, 10 minutes, and10 minutes, respectively.

FIG. 4B illustrates planned workload 412 and executed workload 420.Assuming the tasks of FIG. 4A are completed, the performer confirms WH/O1001, which is indicated in executed workload 420. The executed workloadis identified as GUID 1, which identifies the information in the row ofexecuted workload 420. The completed process is shown as PICK, from areaPI01, of type WH/O, with the WH/O document reference ID 1001. Theplanned duration is also indicated with the executed duration (EDURA),which is also referred to as the actual duration or actual time ofperformance. The estimated duration was 30 minutes, and the executedduration was 32 minutes, which could be evaluated for compliance withacceptable standards.

When WH/O 1001 was completed, the goods would be picked from bins andsitting in a picking area. To further the process of outbound delivery,the system may also generate two Pick HUs (handling units), 2001 and2002, into which the picked goods should be aggregated. Planned workload412 identifies the work for HU 2001 by ID 4714, and the work for HU 2002by ID 4715. Each HU has a Packing, Staging, and Loading phase (whichwill replace the equivalent phases of WH/O 1001) with respect to thegoods, to be executed in areas PA01, ST01, and LO01, respectively.Planned durations are indicated for each phase of the work.

When the work associated with planned workload 412 is accomplished, theWTs of planned workload 410 can be confirmed. FIG. 4C illustrates thatwhen the WTs are confirmed, the system can create WH/O 1004, whichrepresents the aggregate of time (20+30+10=60 minutes total) for thethree WTs (12345, 12346, and 12347, respectively) for the Packing phase.WH/O 1004 replaces the WTs within the system as identifying the Packingwork executed. Thus, executed workload 422 illustrates the informationof executed workload 420, and additionally includes GUID 2 to identifythe Packing process for WH/O 1004, performed in area PA01. The plannedduration was 60 minutes (PDURA), but the performer was able toaccomplish the task in 45 minutes (EDURA). FIG. 4C also illustratesplanned workload 414, which represents the task of packing HUs 2001 and2002 into HU 2003. Thus, task ID 4716 is created for Staging HU 2003,with a planned duration of 30 minutes, and Loading HU 2003, with aplanned duration of 10 minutes.

When HU 2003 is completed (i.e., HUs 2001 and 2002 are combined into HU2003), the system creates WH/O 1005 for the move of HU 2003 from thePacking are to the Staging area. Note that the work associated with thisphase will be accounted in other phases. As such, no recording documentsare created, and the record of executed workload 422 is not updated withnew data, as seen in FIG. 4D. Thus, there are situations where multipleplanned workloads will be created and data created from those multipleplanned workloads to input into an executed workload. As illustrated inFIG. 4D, planned workload 416 is generated to indicate WH/O 1005 toindicate the move of HU 2003 to Staging. The IDs of the tasks of plannedworkload 416 are 4717. Planned workload 416 also includes the Loadingphase of HU 2003 at LO01. Both tasks of planned workload 416 areexpected to take 10 minutes to complete.

In FIG. 4E, WH/O 1005 is confirmed, and the data included withinexecuted workload 424. WH/O 1006 is also created for the loading of HU2003. The task for WH/O 1006 is 4718. In one embodiment, a warehouse mayonly have a single WH/O open for a single set of goods, and thus, WH/O1006 was not created until WH/O 1005 had been confirmed. Other systemscould function differently. Executed workload 424 is updated with GUID 3indicating the completion of Staging at ST01 of WH/O 1005, with aplanned duration of 10 minutes, and an actual duration of 12 minutes.

FIG. 4F illustrates executed workload 426, which is generated responsiveto confirmation of WH/O 1006. GUID 4 identifies the Loading processassociated with WH/O 1006 at station LO01, with a planned time of 10minutes, and an actual time of 15 minutes. The final executed workloadmay be stored to reflect the work performed for the outbound deliveryrequested in the original warehouse order.

While a particular flow of operation is suggested by FIGS. 4A-4F, itwill be understood that the concepts discussed herein can be applied indifferent implementations without necessarily following the suggestedflow of operation of these figures.

FIG. 5 is a flow diagram of an embodiment of a process for generating anexecuted workload. Flow diagrams as illustrated herein provide examplesof sequences of various process actions. Although shown in a particularsequence or order, unless otherwise specified, the order of the actionscan be modified. Thus, the illustrated implementations should beunderstood only as examples, and the illustrated processes can beperformed in a different order, and some actions may be performed inparallel. Additionally, one or more actions can be omitted in variousembodiments of the invention; thus, not all actions are required inevery implementation. Other process flows are possible.

A management system obtains a warehouse order, 502. The warehouse ordercan be generated within the management system, or can be generated inanother enterprise system and retrieved by the management system,referenced in the management system, or sent to the management system.The management system generates one or more tasks related to thewarehouse order, 504, such as separate tasks for different workassignment, or separate tasks for separate HUs. The management systemgenerates a planned workload record based on the warehouse order and thetasks, 506. In one embodiment, a planned workload is generated and thenassigned to a performer. Alternatively, the planned workload could begenerated specifically for an identified performer. Multiple tasks couldbe generated for multiple performers related to the same warehouseorder.

In one embodiment, a warehouse request is assigned to a wave. When thewave is released, warehouse tasks may be created. The warehouse taskscan then be sorted and filtered. A warehouse order creation rule isdetermined based on the sorting and filtering of the warehouse tasks.The warehouse order is created in accordance with the determinedcreation rule. The warehouse tasks are then assigned to the warehouseorder.

The management system assigns the tasks related to the planned workloadto one or more specific performers, 508. The system may generate taskassignments for each of the assigned tasks, 510. When the performer hasexecuted the work task, the performer indicates the completion of thetask. The management system obtains confirmation of completion of atask, 512. In one embodiment, confirmation information is pushed to themanagement system. Alternatively, the completion information can bestored locally and delivered at specific intervals, or in response to apoll by the management system.

The management system determines the actual time for the task from thecompletion indication, 514. The completion indication may simply be atime value representing the amount of time spent to complete the task,or start and stop times. Comparison of the actual time to the plannedtime can indicate a performance of a performer. The system generates anexecuted workload record based on data in the planned workload and theactual task time, 516. The system stores the executed workload record ina storage system to persist the information, 518.

Besides what is described herein, various modifications may be made tothe disclosed embodiments and implementations of the invention withoutdeparting from their scope. Therefore, the illustrations and examplesherein should be construed in an illustrative, and not a restrictivesense. The scope of the invention should be measured solely by referenceto the claims that follow.

1. A method comprising: receiving a planning electronic recordidentifying a task and indicating at least one performance metric bywhich performance of the task is evaluated including an expected timefor completion; obtaining a confirmation of completion of the task;determining an actual time for completion based on a time of theconfirmation; generating an executed work electronic record based on theplanning electronic record, which identifies the task and performer andindicates a task performance value for at least one of the performancemetrics including the actual time for completion; and storing theexecuted work electronic record in a storage system.
 2. The method ofclaim 1, wherein receiving the planning electronic record identifyingthe task comprises: receiving an electronic record identifying a corebusiness task to perform.
 3. The method of claim 1, wherein receivingthe planning electronic record identifying the task comprises: receivingan electronic record identifying an indirect business task to perform,the indirect business task not being directly related to producing orshipping a product.
 4. The method of claim 1, wherein receiving theplanning electronic record comprises: receiving a task assignmentdocument generated in conjunction with a source document, the sourcedocument including data describing a resource related to the performanceof the task.
 5. The method of claim 4, further comprising: linking theexecuted work electronic record to the source document.
 6. The method ofclaim 1, wherein receiving the planning electronic record indicating theperformance metric comprises: receiving the planning electronic recordindicating an expected time for completion of the task.
 7. The method ofclaim 6, further comprising: obtaining information identifying aspecific resource to be used in performance of the task; adjusting theexpected time for completion of the task based on a recalculation of anexpected time for completion of the task using the specificallyidentified resource; and storing the adjusted expected time in theexecuted work electronic document as the expected time for completion ofthe task.
 8. The method of claim 7, further comprising: comparing theactual time of completion with the adjusted expected time for completionto determine a variance between the expected time for completion of thetask and the actual time of completion of the task.
 9. The method ofclaim 1, further comprising: retrieving multiple executed workelectronic records stored in the storage system, each retrieved recordrelated to an evaluation period; and aggregating performance data fromthe multiple executed work electronic records into a single evaluationreport.
 10. The method of claim 9, wherein retrieving the multipleexecuted work electronic records related to an evaluation periodcomprises: retrieving multiple executed work electronic records relatedto a single performer for the evaluation period.
 11. The method of claim10, wherein aggregating the performance data for the multiple executedwork electronic records related to the single performer comprises:aggregating the performance data according to an organizational unitidentifier, a task type, and a task performance area.
 12. The method ofclaim 9, wherein retrieving the multiple executed work electronicrecords related to an evaluation period comprises: retrieving multipleexecuted work electronic records related to multiple different types oftasks for the evaluation period.
 13. The method of claim 9, furthercomprising: comparing the actual time of completion of tasks with theexpected times for completion of the corresponding tasks as indicated bythe executed work electronic records to generate an evaluationindicator; and storing the evaluation indicator in the evaluationreport.
 14. The method of claim 9, further comprising: comparing theactual attendance of a single performer with expected times forcompletion of the corresponding tasks as indicated by the executed workelectronic records to generate an evaluation indicator; and storing theevaluation indicator in the evaluation report.
 15. An article ofmanufacture comprising a machine readable medium having content storedthereon to provide instructions to cause a machine to perform operationsincluding: receiving a planning electronic record identifying a task andindicating at least one performance metric by which performance of thetask is evaluated including an expected time for completion; obtaining aconfirmation of completion of the task; determining an actual time forcompletion based on a time of the confirmation; generating an executedwork electronic record based on the planning electronic record, whichidentifies the task and performer and indicates a task performance valuefor at least one of the performance metrics including the actual timefor completion; and storing the executed work electronic record in astorage system.
 16. The article of manufacture of claim 15, wherein thecontent to provide instructions for receiving the planning electronicrecord identifying the task comprises content to provide instructionsfor receiving an electronic record identifying an indirect labor toperform, the indirect labor not being directly related to producing orshipping a product.
 17. The article of manufacture of claim 15, whereinthe content to provide instructions for receiving the planningelectronic record indicating the performance metric comprises content toprovide instructions for receiving the planning electronic recordindicating an expected time for completion of the task.
 18. The articleof manufacture of claim 17, further comprising content to provideinstructions for obtaining information identifying a specific resourceto be used in performance of the task; adjusting the expected time forcompletion of the task based on a recalculation of an expected time forcompletion of the task using the specifically identified resource; andstoring the adjusted expected time in the executed work electronicdocument as the expected time for completion of the task.
 19. Thearticle of manufacture of claim 15, further comprising content toprovide instructions for retrieving multiple executed work electronicrecords stored in the storage system, each retrieved record related toan evaluation period; and aggregating performance data from the multipleexecuted work electronic records into a single evaluation report.
 20. Asystem comprising: a work execution station at which a performerexecutes a task, and generates performance data related to performanceof the task and a completion indicator to indicate completion of thetask; and a warehouse management system coupled to the work executionstation, the warehouse management system to generate a planned workloadidentifying the task and indicating at least one performance metric bywhich performance of the task is evaluated including an expected timefor completion of the task; send the planned workload to the workexecution station to trigger execution of the task; receive theperformance data and completion indicator from the work executionstation; determine an actual performance time for completion of thetask; generate an executed workload with data of the planning electronicrecord and information to indicate the performer and a task performancevalue for at least one of the performance metrics including the actualperformance time; and store the executed workload in a storage system.21. The system of claim 20, wherein the work execution station generatesperformance data related to performance of the task, includingperformance values for one or more engineered labor standards.
 22. Thesystem of claim 20, wherein the warehouse management system furtheraggregates performance data from the multiple executed workloads into asingle evaluation report for a period of evaluation.